eter is of type PTR, the actual parameter may be of any pointer type.
The procedures contained in module SYSTEM are listed in the following tables. Most of them correspond to single instructions compiled as in-line code. For details, the reader is referred to the processor manual. v stands for a variable, x, y, a, and n for expressions, and T for a type.
Function procedures
Name Argument types Result type Function
ADR(v) any LONGINT address of variable v
BIT(a, n) a: LONGINT BOOLEAN bit n of Mem[a]
n: integer
CC(n) integer constant BOOLEAN condition n (0 <= n <= 15)
LSH(x, n) x: integer, CHAR, BYTE type of x logical shift
n: integer
ROT(x, n) x: integer, CHAR, BYTE type of x rotation
n: integer
VAL(T, x) T, x: any type T x interpreted as of type T
Proper procedures
Name Argument types Function
GET(a, v) a: LONGINT; v: any basic type, v := Mem[a]
pointer, procedure type
PUT(a, x) a: LONGINT; x: any basic type, Mem[a] := x
pointer, procedure type
GETREG(n, v) n: integer constant; v: any basic type, v := Register n
pointer, procedure type
PUTREG(n, x) n: integer constant; x: any basic type, Register n := x
NEW(v, n) v: any pointer; n: integer allocate storage block of n bytes
assign its address to v
Appendix D: The Oberon Environment
Oberon-2 programs usually run in an environment that provides command activation, garbage collection, dynamic loading of modules, and certain run time data structures. Although not part of the language, this environment contributes to the power of Oberon-2 and is to some degree implied by the language definition. Appendix D describes the essential features of a typical Oberon environment and provides implementation hints. More details can be found in [1], [2], and [3].
D1. Commands
A command is any parameterless procedure P that is exported from a module M. It is denoted by M.P and can be activated under this name from the shell of the operating system. In Oberon, a user invokes commands instead of programs or modules. This gives him a finer grain of control and allows modules with multiple entry points. When a command M.P is invoked, the module M is dynamically loaded unless it is already in memory (see D2) and the procedure P is executed. When P terminates, M remains loaded. All global variables and data structures that can be reached from global pointer variables in M retain their values. When P (or another command of M) is invoked again, it may continue to use these values.
The following module demonstrates the use of commands. It implements an abstract data structure Counter that encapsulates a counter variable and provides commands to increment and print its value.
MODULE Counter;
IMPORT Texts, Oberon;
VAR
counter: LONGINT;
w: Texts.Writer;
PROCEDURE Add*; (* takes a numeric argument from the command line *)
Counter.Add n adds the value n to the variable counter
Counter.Write writes the current value of counter to the screen
Since commands are parameterless they have to get their arguments from the operating system. In general, commands are free to take arguments from everywhere (e.g. from the text following the command, from the most recent selection, or from a marked viewer). The command Add uses a scanner (a data type provided by the Oberon system) to read the value that follows it on the command line.
When Counter.Add is invoked for the first time, the module Counter is loaded and its body is executed. Every call of Counter.Add n increments the variable counter by n. Every call of Counter.Write writes the current value of counter to the screen.
